home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000203_news@columbia.edu _Fri Dec 29 21:28:44 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id VAA21763 for <kermit.misc@watsun>; Fri, 29 Dec 1995 21:28:42 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id VAA28154 for kermit.misc@watsun; Fri, 29 Dec 1995 21:28:40 -0500 (EST)
  4. Path: news.columbia.edu!panix!news.eecs.umich.edu!newshost.marcam.com!uunet!in2.uu.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times)
  8. Message-ID: <1995Dec29.173301.70177@cc.usu.edu>
  9. Date: 29 Dec 95 17:33:01 MDT
  10. References: <4bcrfp$lvh@piano.synapse.net> <4bt2qs$ap@gaia.ns.utk.edu> <4c1kem$j5r@huron.eel.ufl.edu>
  11. Organization: Utah State University
  12. Lines: 108
  13.  
  14. In article <4c1kem$j5r@huron.eel.ufl.edu>, afn10375@afn.org (David A. Johns) writes:
  15. > Joe Doupnik (jrd@cc.usu.edu) wrote:
  16. > 
  17. > #   > Out of curiosity, do any of these priorities involve                  
  18. > #   > MSDOS-Kermit, or has development on that platform essentially         
  19. > #   > stopped?                                                              
  20. > #   -----------
  21. > #           I hope you favor dogs rather than cats, given what 
  22. > #   curiosity does. Just what is it that you need?
  23.  
  24.     That's quite a wish-list David, and a couple days after the
  25. official due-date! But let me add a few comments on the items as we
  26. talk here on News.
  27.   
  28. > Well, I think my vote would go for more functionality in the 
  29. > scrollback buffers (mark and save, search, buffer input while viewing 
  30. > the buffer, etc.) and a real plain-text session log (and yes, I have 
  31. > read the .bwr).  
  32.  
  33.     I guess you mean full editing, and hence a reasonably competant
  34. full screen editor to match. That's quite a bit of code, and any editor
  35. would have to work by shutting off comms so that screen and keys remain
  36. strictly local. Also the scroll back buffer normally lives above 1MB, in 
  37. expanded memory. That means the editor needs spill buffers up there too
  38. to handle the large rollback buffers permitted by MSK. I think its easy
  39. to see that this can get out of hand.
  40.     The session log is plain-text if that's all the host sends to us.
  41. Which means it sends a line of text followed by CR/LF, and no cursor 
  42. steering, screen embellishments (bold, reverse video, etc), whatnot that
  43. make up full screen work rather than glass-tty work. Otherwise our screen
  44. is likely decorated semi-randomly as the cursor is moved here and there,
  45. and thus what we see isn't the way things arrive or logged.
  46.   
  47. > I'd also like to see a way to preserve the scrollback buffer when 
  48. > logging out of a TCP session.
  49.  
  50.     It is preserved, actually. But to see it we must be in terminal
  51. emulation mode where the character sets and visual attributes are available.
  52. It is available when a new session is started, or when we rollback during
  53. another session.
  54.   
  55. > A nice addition to the script language would be a handful of 
  56. > user-defined string triggers, like the string that starts automatic 
  57. > ZModem downloads in programs that have that (I think NetTerm, a 
  58. > winsock program, also watches for the KERMIT READY TO SEND signal and 
  59. > starts a download hands-off).
  60.   
  61.     We've thought about these too. It might help to understand how
  62. matters work. Triggers require that MSK buffer bytes entering the terminal
  63. emulator, do not act on them, and do parsing of the accumulated stream as
  64. each byte arrives. MSK does this for host-triggered printing, and for the
  65. APC command. Those commands are well structured, short, and unambiguous
  66. (not overlapping any other acceptable commands). So, accumulation/constant
  67. reparsing without display and hence bursty screen updates (if any sometimes)
  68. turns out to be not what people would accept, nor would I for that matter.
  69.     We put a lot of thought into the security side too. Whatever happens
  70. must be safe and under control of the user; no launch and forget strategy.
  71. That means we don't launch external programs based on arbitrary strings
  72. arriving. Not only do such strings happen in other circumstances (rather
  73. like the Hayes triple + syndrome) but the consequences may not be what the
  74. user can live with.
  75.   
  76. > Someone else has just mentioned having full access to the input 
  77. > buffer.  I managed to use \v(input) to get the IP address on a SLIP 
  78. > line (thus fully automating the process you outline in the network 
  79. > docs), but I can imagine it would be nice to be able to work with more 
  80. > than one line.
  81.  
  82.     As mentioned previously, a succession of INPUT statements can
  83. gather a succession of "lines", so that facility exists now.
  84.   
  85. > It would be nice to have input that comes in while at the command 
  86. > prompt (like when a macro is running or during a transmit) piped back 
  87. > into the emulator so that they end up in the log and the buffer.
  88.  
  89.     You have a point. It's not possible presently. I should caution
  90. that INPUT is not always running and hence there are gaps in the INPUT
  91. buffer stream, and that stream wraps in its circular buffer. INPUT material
  92. does go into the session log.
  93.  
  94. > Right now if you call MSK from another program it can read the port 
  95. > speed, but not the parity.  I have one system I call that uses 7o1 
  96. > (yes, odd parity), so in order to write general transfer scripts (in 
  97. > Commo's macro language), I have to parse out the parity and send it to 
  98. > Kermit.  Since DOS reports the parity (with MODE and MSD, at least), 
  99. > it seems that Kermit should be able to read it.  
  100.  
  101.     ? MSK does not run UART chips with hardware parity. Hardware
  102. parity is a nice way of not communicating due to differences at each
  103. end. MSK uses parity in software and it is highly forgiving during terminal
  104. emulation (SET DISPLAY 7/8 etc). Furthermore, during file transfers MSK
  105. automatically determines parity as much as is possible, and switches to
  106. it with a message. I can add code to probe the UART for existing parity,
  107. if that would really do a lot of good.
  108.   
  109. > By the way, I use Commo, calling Kermit for special purposes rather 
  110. > than using Kermit for everything primarily because of the first three 
  111. > suggestions above.
  112. >  
  113. > I could probably think of more if you're interested.
  114.  
  115.     Wishlists are always welcomed, even though only portions are
  116. possible to include in the programs.
  117.  
  118. > David Johns
  119.  
  120.     Thanks David,
  121.     Joe D.